'\" te
.\" Copyright (c) 2006, Sun Microsystems, Inc., All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH USB_ISOC_REQUEST 9S "April 9, 2016"
.SH NAME
usb_isoc_req, usb_isoc_req_t, usb_isoc_request \- USB isochronous request structure
.SH SYNOPSIS
.nf
#include <sys/usb/usba.h>
.fi

.SH INTERFACE LEVEL
illumos DDI specific (illumos DDI)
.SH DESCRIPTION
A request sent through an isochronous pipe is used to transfer large amounts of
packetized data with relative unreliability, but with bounded service periods.
A packet is guaranteed to be tried within a bounded time period, but is not
retried upon failure. Isochronous transfers are supported on both USB 1.1 and
USB 2.0 devices. For further information, see section \fI5.6\fR of the \fIUSB
2.0\fR specification available at \fIwww.usb.org\fR.
.sp
.LP
This section provides information on acceptable combinations of flags and
attributes with additional details. The following fields of the usb_isoc_req_t
are used to format an isochronous request.
.sp
.in +2
.nf
usb_frame_number_t
                isoc_frame_no;   /* frame num to start sending req. */
ushort_t       isoc_pkts_count; /* num USB pkts in this request */
/*
 * The sum of all pkt lengths in an isoc request. Recommend to set it to
 * zero, so the sum of isoc_pkt_length in the isoc_pkt_descr list will be
 * used automatically and no check will be apply to this element.
 */
ushort_t       isoc_pkts_length;
ushort_t       isoc_error_count;/* num pkts completed w/errs */
usb_req_attrs_t isoc_attributes;/* request-specific attrs */
mblk_t          *isoc_data;     /* data to xfer */
                                 /* IN or OUT: alloc. by client. */
                                 /* Size=total of all pkt lengths. */
usb_opaque_t     isoc_client_private; /* for client driver excl use. */
struct usb_isoc_pkt_descr       /* (see below) */
                 *isoc_pkt_descr;

/*
 * Normal callback function, called upon completion.
 * This function cannot block as it executes in soft interrupt context.
 */
void       (*isoc_cb)(
                usb_pipe_handle_t ph, struct usb_isoc_req *req);

/* Exception callback function, for error handling. */
void       (*isoc_exc_cb)(
               usb_pipe_handle_t ph, struct usb_isoc_req *req);

usb_cr_t  isoc_completion_reason; /* overall completion status */
                                   /* set by USBA framework */
                                   /* See usb_completion_reason(9S) */
usb_cb_flags_t  isoc_cb_flags;    /* recovery done by callback hndlr */
                                   /* set by USBA on exception. */
                                   /* See usb_callback_flags(9S) */
.fi
.in -2

.sp
.LP
A \fBusb_isoc_pkt_descr_t\fR describes the status of an isochronous packet
transferred within a frame or microframe. The following fields of a
\fBusb_isoc_pkt_descr_t\fR packet descriptor are used within an
\fBusb_isoc_req_t\fR. The \fBisoc_pkt_length\fR is set by the client driver to
the amount of data managed by the packet for input or output. The latter two
fields are set by the \fBUSBA\fR framework to indicate status. Any packets with
an \fBisoc_completion_reason\fR, other than \fBUSB_CR_OK\fR, are reflected in
the \fBisoc_error_count\fR of the \fBusb_isoc_req_t\fR.
.sp
.in +2
.nf
     ushort_t    isoc_pkt_length;        /* number bytes to transfer */
      ushort_t    isoc_pkt_actual_length; /* actual number transferred */
      usb_cr_t    isoc_pkt_status;        /* completion status */
.fi
.in -2

.sp
.LP
If two multi-frame \fBisoc\fR requests that both specify the
\fBUSB_ATTRS_ISOC_XFER_ASAP\fR attribute are scheduled closely together, the
first frame of the second request is queued to start after the last frame of
the first request.
.sp
.LP
No stalls are seen in isochronous transfer exception callbacks. Because
transfers are not retried upon failure, isochronous transfers continue
regardless of errors.
.sp
.LP
Request attributes define special handling for transfers. The following
attributes are valid for isochronous requests:
.sp
.ne 2
.na
\fB\fBUSB_ATTRS_ISOC_START_FRAME\fR\fR
.ad
.RS 30n
Start transferring at the starting frame number specified in the
\fBisoc_frame_no\fR field of the request.
.RE

.sp
.ne 2
.na
\fB\fBUSB_ATTRS_ISOC_XFER_ASAP\fR\fR
.ad
.RS 30n
Start transferring as soon as possible. The \fBUSBA\fR framework picks an
immediate frame number to map to the starting frame number.
.RE

.sp
.ne 2
.na
\fB\fBUSB_ATTRS_SHORT_XFER_OK\fR\fR
.ad
.RS 30n
Accept transfers where less data is received than expected.
.RE

.sp
.LP
The \fBusb_isoc_req_t\fR contains an array of descriptors that describe
isochronous packets. One isochronous packet is sent per frame or microframe.
Because packets that comprise a transfer are sent across consecutive frames or
microframes, \fBUSB_ATTRS_ONE_XFER\fR is invalid.
.sp
.LP
See \fBusb_request_attributes\fR(9S) for more information.
.sp
.LP
Isochronous transfers/requests are subject to the following constraints and
caveats:
.sp
.in +2
.nf
1) The following table indicates combinations of usb_pipe_isoc_xfer
   flags argument and fields of the usb_isoc_req_t request argument
   (X = don't care). (Note that attributes considered in this table
   are ONE_XFER, START_FRAME, XFER_ASAP, and SHORT_XFER, and that
   some transfer types are characterized by multiple table entries.)

Flags Type     Attributes          Data    Semantics
---------------------------------------------------------------
X      X      X                    NULL    illegal

X      X      ONE_XFER             X       illegal

X      X      ISOC_START_FRAME     X       illegal
              & ISOC_XFER_ASAP

X      X      !ISOC_START_FRAME    X       illegal
              & !ISOC_XFER_ASAP

X      OUT    SHORT_XFER_OK        X       illegal

X      IN     X                    !=NULL  See table note (A)

X      X      ISOC_START_FRAME     !=NULL  See table note (B)

X      X      ISOC_XFER_ASAP       !=NULL  See table note (C)

Table notes:

    A) continuous polling, new data is returned in
       cloned request structures via continuous callbacks,
       original request is returned on stop polling

    B) invalid if the current_frame number is past
       "isoc_frame_no" or "isoc_frame_no" == 0

    C)"isoc_frame_no" is ignored. The USBA framework
       determines which frame to insert and start
       the transfer.

2) USB_FLAGS_SLEEP indicates to wait for resources but
   not for completion.

3) For polled reads:

  A. The USBA  framework  accepts  a  request  which
     specifies  the  size and number of packets to fill
     with data. The packets get filled one  packet  per
     (1  ms)  frame/(125 us) microframe.  All  requests
     have an implicit USB_ATTRS_SHORT_XFER_OK attribute
     set, since transfers  continue in spite of any en-
     countered. The amount of data read per packet  will
     match  the  isoc_pkt_length  field  of  the packet
     descriptor unless a  short  transfer  occurs.  The
     actual     size     is     returned     in     the
     isoc_pkt_actual_length   field   of   the   packet
     descriptor.  When  all packets of the request have
     been processed, a normal callback is done to  sig-
     nal the completion of the original request.

  B. When continuous polling is stopped, the original
     request is returned in an exception callback with a
     completion reason of USB_CR_STOPPED_POLLING.
     (NOTE: Polling can be restarted from  an exception
     callback corresponding to an original request.
     Please see usb_pipe_isoc_xfer(9F) for more information.

  C. Callbacks must be specified.

  The isoc_completion_reason indicates the status of the transfer. See
  usb_completion_reason(9s) for usb_cr_t definitions.

  The isoc_cb_flags are set prior to calling the exception
  callback handler to summarize recovery actions taken and
  errors encountered during recovery. See usb_callback_flags(9s)
  for usb_cb_flags_t definitions.

--- Callback handling ---
All usb request types share the same callback handling. Please see
usb_callback_flags(9s) for a description of use and operation.
.fi
.in -2

.SH ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
.sp

.sp
.TS
box;
c | c
l | l .
ATTRIBUTE TYPE	ATTRIBUTE VALUE
_
Architecture	PCI-based systems
_
Interface stability	Committed
.TE

.SH SEE ALSO
.BR attributes (7),
.BR usb_alloc_request (9F),
.BR usb_get_current_frame_number (9F),
.BR usb_get_max_pkts_per_isoc_request (9F),
.BR usb_pipe_bulk_xfer (9F),
.BR usb_pipe_ctrl_xfer (9F),
.BR usb_pipe_intr_xfer (9F),
.BR usb_pipe_isoc_xfer (9F),
.BR usb_bulk_request (9S),
.BR usb_callback_flags (9S),
.BR usb_completion_reason (9S),
.BR usb_ctrl_request (9S),
.BR usb_intr_request (9S),
.BR usb_request_attributes (9S)
